FYI these were the final annotations that made things work correctly for me

{
					"alb.ingress.kubernetes.io/certificate-arn": helm.values.userSettings.certificateArn
					"alb.ingress.kubernetes.io/group.name":      "flyte"
					"alb.ingress.kubernetes.io/listen-ports":    '[{"HTTPS":443}]'
					"alb.ingress.kubernetes.io/scheme":          "internet-facing"
					"alb.ingress.kubernetes.io/ssl-redirect":    "443"
					"alb.ingress.kubernetes.io/target-type":     "ip"
					"kubernetes.io/ingress.class":               "alb"
					"alb.ingress.kubernetes.io/inbound-cidrs":   "xxx.xxx.xxx.xxx,xxx.xxx.xxx.xxx"
				}```

In general I would avoid pointing to an external guide, give also that the guide you are referring to is mostly referring to the single binary deployment, which might be confusing. I think all documentation should be in one place

Agree. A second iteration of updates to these guides should be pointed to extend the reach and make it more actionable. Also expanding the tutorial in the https://github.com/unionai-oss/deploy-flyte repo to cover flyte-core

what if we forked your guide, @davidmirror-ops , and moved it to flyteorg?

@eapolinario I was thinking of something similar. Moving forward, the idea is that TF is the preferred approach but a manual guide is always a good resource

I'd expand on what service-account-name should be here.
If I understand correctly this is a separate service account, created in the data plane, which will be assume by the flyteadmin service account in the control plane to generate all the required resources in the data plane, right?

I would not use the word "upload" which might be misleading. I'd say that you need update your control plane configuration with the new secrets

Are we assuming that we have 3 dataplanes or 2? Since in the first case we only need 2 entries. I'd also specify how to change the names of the clusters

typo: tha -> the

Isn't this also the one used for flyte-core using ALB? I'd add that too

Why are we removing this section?

I'm just not sure how it fits here. Additionally is not clear what specific K8s resources it refers to (besides namespaces for projects, which is only an example). So this relationship between Flyte objects and K8s resources is worth documenting, but I'm not sure it fits in this sort of pre-requisites section.

It is not clear what the word "shared" means here.

Added a reference to the sharding mechanism

You actually need 2 sets of policies, one for the control plane and one for the data plane

Are you defining different permissions for control and data plane? The set of perms indicated here work for both

ideally they should be different, but initially they may be the same

controlplane -> control plane

No need to put an actual secret here

I'd suggest to use directly encoded data here since the new lines are error prone

Right.
So you mean also modifying the previous command to avoid the -D and also using a data section, right?

yes

No need for an actual token

No need for an actual cert

Make sure to explain here what these weight values are

I think you also need the configuration for datacatalog; in my case I had to also add the endpoint for that.
Note that this should be moved to the default charts and not left to the user

I'd explain here that ideally we would add only the namespaces needed, i.e. project-env, so that users can be more specific if they want

Can we make this an inexistent url? Maybe rename this to '<your.flyte.url>' ?

Isn't the default k8s container runtime containerd?

what if we forked your guide, @davidmirror-ops , and moved it to flyteorg?